Skip to main content
QMSQMS
QMS
  • Welcome to your QMS
  • Quality Manual
  • Procedures
  • Records
  • TF_Legit.Health_Plus
    • Legit.Health Plus TF index
    • Legit.Health Plus STED
    • Legit.Health Plus description and specifications
    • R-TF-001-007 Declaration of conformity
    • GSPR
    • Clinical
    • Design and development
    • Design History File (DHF)
      • Version 1.0.0.0
        • Requirements
          • REQ_001 The user receives quantifiable data on the intensity of clinical signs
          • REQ_002 The user receives quantifiable data on the count of clinical signs
          • REQ_003 The user receives quantifiable data on the extent of clinical signs
          • REQ_004 The user receives an interpretative distribution representation of possible ICD categories represented in the pixels of the image
          • REQ_005 The user can send requests and get back the output of the device as a response in a secure, efficient and versatile manner
          • REQ_006 The data that users send and receive follows the FHIR healthcare interoperability standard
          • REQ_007 If something does not work, the API returns meaningful information about the error
          • REQ_008 Notify the user if the image does not represent a skin structure
          • REQ_009 Notify the user if the quality of the image is insufficient
          • REQ_010 The device detects if the image is of clinical or dermatoscopic modality
          • REQ_011 The user specifies the body site of the skin structure
          • REQ_012 Users can easily integrate the device into their system
          • REQ_013 The user receives the pixel coordinates of possible ICD categories
          • ignore-this
            • SWR-001- Users of the REST API can log in and receive an access token
            • SWR-002- The REST API enforces HTTPS for all communications to ensure data security
            • SWR-003- The REST API implements rate limiting to prevent abuse
            • SWR-004- The REST API verifies the access token for every request to secure endpoints
            • SWR-005- Data exchanged with clinical endpoints of the API adhere to the FHIR standard
            • SWR-006- The REST API only accepts and outputs images in Base64 format
            • SWR-007- The diagnosis support service accepts multiple images to deliver more accurate results
            • SWR-008- The user's password is stored in the database as a hashed password
            • SWR-009- New users of the device are only created by an internal user registration service
        • Test plans
        • Test runs
        • 🥣 SOUPs
    • IFU and label
    • Post-Market Surveillance
    • Quality control
    • Risk Management
  • Licenses and accreditations
  • External documentation
  • Procedures
  • Records
  • TF_Legit.Health_Plus
  • Design History File (DHF)
  • Version 1.0.0.0
  • Requirements
  • ignore-this
  • SWR-005- Data exchanged with clinical endpoints of the API adhere to the FHIR standard

SWR-005- Data exchanged with clinical endpoints of the API adhere to the FHIR standard

Internal IDSWR_005
TitleData exchanged with clinical endpoints of the API adhere to the FHIR standard
CategoryUSER INTERFACE REGULATORY
ImportanceHIGH
SystemREST API
Editor(s)Alejandro Carmena Magro , JD-017
SupervisorAlfonso Medela , JD-005
ApprovalPending
Created at20 Jun 2024

Description​

FHIR (Fast Healthcare Interoperability Resources) is a standard for exchanging healthcare information electronically. It was created by the Health Level Seven International (HL7) organization. FHIR aims to simplify and accelerate the interoperability of healthcare data by using modern web technologies, fostering better collaboration and care coordination across the healthcare ecosystem.

FHIR takes a modular approach, breaking healthcare data into discrete, structured "resources" such as patients, medications, and observations. These resources can be easily shared and understood across different systems. It uses RESTful APIs, which are common in web services, making it straightforward to implement and integrate with existing technologies. FHIR supports multiple data formats, including JSON and XML, making it flexible and adaptable to various technology stacks.

We'll use the JSON format to represent FHIR resources in our API for data exchange. This involves all the JSON documents sent and received in the request and response bodies from the clinical API endpoints.

Rationale​

Adopting the FHIR standard will make it easier for developers to integrate our software with their existing medical records and clinical applications.

Source​

  • Taig Mac Carthy
  • Industry best practices

Tested by software tests​

  • PLAN_010: Validation of request and response data against FHIR schemas

Activities generated​

  • Develop the JSON schemas for requests and responses based on FHIR resource definitions.
  • Implement validation mechanisms to ensure all data exchanged via the API endpoints conform to FHIR standards.
  • Update API documentation to include information about FHIR-compliant data formats.

Implements user needs​

The requirement addresses the need for interoperability with other healthcare systems, enabling users to integrate the software with their existing electronic health record (EHR) systems. This integration enhances data management efficiency and supports better clinical decision-making.

Regulatory requirements​

5.1: The device shall be compliant with MDR 2017/745, Annex I, point 14.5

Causes failure modes​

  • Incorrect implementation of FHIR schemas leading to data exchange errors, and incompatibility with some healthcare systems due to deviations from the standard. These could result from improper validation or incorrect interpretation of FHIR resource definitions.

Implements risk control measures​

  • It mitigates risks related to data inconsistency, misinterpretation of results and incompatibility by enforcing the use of well-defined, standardized data formats.
  • Compliance with FHIR also ensures adherence to regulatory standards, thereby reducing the risk of legal and operational issues.

Acceptance criteria​

  • All JSON requests and responses for the API endpoints are validated against the corresponding FHIR resource schemas.
  • Successful data exchange with external systems that use FHIR standards without errors or data loss.
  • Comprehensive documentation detailing the implementation of FHIR standards in the API.

Constraints​

  • Use FHIR standard version 5.0 or higher.
  • Use only non-experimental FHIR data types and resource types.

Dependencies​

There are no specific dependencies for this requirement. However, it is essential to ensure that the implementation remains up-to-date with any changes or updates to the FHIR standard.

Performance considerations​

Ensure that the validation of JSON documents against FHIR schemas does not significantly impact the response time of the API endpoints.

Additional notes​

Regular training and updates for the development team on FHIR standards and best practices will be necessary to maintain compliance and optimize implementation.

Revision history​

VersionDateAuthorDescription
Previous
SWR-004- The REST API verifies the access token for every request to secure endpoints
Next
SWR-006- The REST API only accepts and outputs images in Base64 format
  • Description
  • Rationale
  • Source
  • Tested by software tests
  • Activities generated
  • Implements user needs
  • Regulatory requirements
  • Causes failure modes
  • Implements risk control measures
  • Acceptance criteria
  • Constraints
  • Dependencies
  • Performance considerations
  • Additional notes
  • Revision history
All the information contained in this QMS is confidential. The recipient agrees not to transmit or reproduce the information, neither by himself nor by third parties, through whichever means, without obtaining the prior written permission of Legit.Health (AI LABS GROUP S.L.)